In wireless communication systems, the process of scheduling plays an important role for the overall performance. Scheduling is normally part of the general resource management, and typically involves allocating communication resources, such as the transmission resources of a shared radio medium, to users.
The scheduler is normally a key element to provide higher data rates, reduced latency and improved system capacity. There is thus a general demand for efficient scheduling in wireless communication systems, and especially in the radio access networks. Examples include radio access networks such as GSM EDGE Radio Access Network (GERAN), UMTS Terrestrial Radio Access Network (UTRAN) and Evolved UTRAN (E-UTRAN).
For example, in E-UTRAN, which forms part of the Long Term Evolution (LTE) system, the scheduler assigns radio resources, also called Resource Blocks, for the downlink as well as for the uplink using the Physical Downlink Control CHannel (PDCCH).
For the uplink, the scheduling may for example operate based on a request-grant principle, where a user terminal, or User Equipment (UE), 10 requests, by a scheduling request, permission to transmit data and a network node 20 handling the scheduling on the network side provides a grant for the uplink transmission, as schematically illustrated in FIG. 1. Other types of scheduling principles are also possible.
The network side normally needs information about the current state of the data packet buffers in the UEs.
In LTE, for example, this information can be sent from the UEs to the network side by means of a Scheduling Request (SR) and/or a Buffer Status Report (BSR). The Scheduling Requests are normally transmitted on a control channel such as the Physical Uplink Control CHannel (PUCCH), while the Buffer Status Reports are typically transmitted on the data channel such as the Physical Uplink Shared CHannel (PUSCH).
By way of example, in LTE, a UE may request uplink resources on PUSCH by sending a PUCCH format 1/1a/1b on its given SR resources, upon which the network will respond with an uplink grant indicating on which PUSCH resources the UE may transmit. Alternatively, if Semi Persistent Scheduling (SPS) is used, the uplink grant only needs to be sent once and is thereafter valid until SPS deactivation or reconfiguration.
The amount of data the UE has buffered, and hence needs to transmit on PUSCH, may be indicated via a subsequent BSR in the first PUSCH transmission. This information is however of no use for applications where packets are generated intermittently in the UE, such as e.g. for VoIP, where new speech frames are generated every 20 ms, and there will only occasionally be data packets in the buffer. This means that the network will not have any information of when the UE will need to transmit its next VoIP frame until it receives the very next SR. In this context, it should be kept in mind that the UE can only send a SR at those instances given by the scheduling request opportunities allocated to the UE by the network. This means that that there may be a considerable time delay until the network is actually informed about the need of the UE to transmit a packet.
The network generally needs to balance two different, and conflicting, requirements regarding the uplink scheduling:                In order to keep the delays as low as possible and/or to create extra delay slack for the benefit of Radio Resource Management (RRM) flexibility, the PUSCH transmission ought to take place as soon as possible after an application level packet (e.g. a VoIP frame) has been generated in the UE.        In order to optimize system efficiency, the network should avoid over-provisioning of PUSCH resources to one and the same UE. Otherwise this approach could be used to keep the delays low.        
VoIP is not the only application that has such intermittent or periodic behavior. Other applications exhibiting this behavior include gaming applications. Games often use a periodic state update, for example, 50 states/second that can for example be in sync with the frame rate (frames/sec) of the game. In contrast to VoIP, games have a somewhat random behavior due to the fact that the application can experience situations where it can not maintain its target frames/sec resulting in a delay/offset in the periodic behavior.
Keeping the delays to a minimum whilst simultaneously also avoiding over-provisioning of PUSCH resources to a UE, would require a perfect “synchronization” between UE application layer packet generation and uplink transmission on PUSCH. In other words, it will require the network to be fully aware of exactly when in time the application level packets are generated and thereafter schedule the PUSCH accordingly.
UE application layer packet generation could experience jitter and delays that would offset static sync generation that assumes constant inter-arrival time. For example, games can have a fixed rate game engine running for example 50 states/second (i.e. frames per second) that generate packets with 20 ms periodicity, but can randomly stall when some process intensive action occurs in the game, thus losing synchronization. Games are also very latency sensitive.
A solution for games would be to give very short SR periodicity, i.e. 1 ms, on PUCCH, but this is not possible in practice due to the common situation of high number of users in connected mode. As an example 700 users in a cell would need close to 40% of the uplink for SR on a 10 MHz carrier with 1 ms periodicity. This is not acceptable in practice.
Hence there is still a general demand for solutions that can effectively handle the conflicting requirements of delay and over-provisioning with regard to uplink scheduling.
Reference [1] uses Radio Resource Control (RRC) reconfiguration giving short SR periodicity to probe synchronization, but would need RRC reconfiguration every time synchronization is lost.
Reference [2] relates to uplink delay scheduling, and more specifically the computation of a delay time parameter that can be used to make better scheduling decisions.